Business entities require business software for performing an array of essential tasks, such as communication, planning, inventory control, order processing, systems monitoring, and nearly every facet of a business' operations. A business entity often requires a software solution with features, interfaces, data management, and other aspects unique to that one specific company. Yet, core functions may be similar among the different unique solutions. These core functions may be provided to several, unique business entities, e.g., companies. In addition to needing to vary several initial deployments among a variety of customer-companies, these varied implementations may need constant updating, to evolve with the evolving business' needs.
Software developers may design and provide a set of software tools in a generic or universal form. These tools may provide a functional foundation for a software suite (e.g., a plurality of related applications). The software suite may provide various interfaces to released objects (e.g., public objects) so that end-user clients may customize various aspects of their specific install of the software suite. With customer configuration data, customers may be able to modify every aspect of their software experience, including defining the user interfaces, what functions are available on the interfaces, and/or what fields are provided to the user.
To help maintain these software packages, SAP AG (a developer) introduced an enhancement package strategy as a means to simplify the way customers manage and deploy new software functionality. Customers may selectively implement these software innovations from a developer and activate the software upon business demand. As a result, customers can isolate the impact of software updates from introducing/rolling out new functionality and bring new functionality online faster through shortened testing cycles. Customers no longer have to plan for major releases every few years. They may now choose to selectively implement the business functions or technical improvements that add the value that matters most to their business. A developer may use enhancement packages to quickly and easily deliver business and industry-specific functionality, enterprise services, and other functions that help improve and simplify the use of software through user interface and other end-to-end process improvements.
These enhancement packages may be cumulative from a functional perspective, e.g., current enhancement packages may contain the entire content of earlier packages. So each enhancement package may be based on the previous one. Enhancement packages may also have the same maintenance duration as the underlying core application. Each enhancement package may contain new versions of existing software components. With the enhancement packages customers can choose which software components are updated in their systems, depending on the new/extended functionality they want to use. The enhancement package architecture provides flexibility for software updates and maintenance, it may also provide some conflicts, especially for applications built on top of the underlying software suite, but not fully integrated into the core software.
Modular Business Applications (“MBA”) were designed to address the business priorities of very specific, sometimes small customer/user segments. In order to serve a greater number of customers with specific solutions, the MBAs offer AddOn solutions based on already released products for the installed base, e.g., current users of the underlying software suite. The MBAs may allow for quick delivery of solutions that may be sold without serious discount, may even be restricted to certain regions or languages, and may be limited in their compatibility to a single release only, thus reducing the risk of creating long-term maintenance obligations. Customers may benefit from the MBAs by gaining additional functional scope, tailored to their particular business need, and built on top of the already installed and familiar stable core.
Modular Business Applications may be delivered as AddOns for software versions that are already released and delivered to customers. These released product versions may contain public objects and private objects. The private objects may be tested to ensure correct operation with the aspects of the underlying software that makes calls to the private objects (e.g., the private objects are only called by the core software from the same developer). The public objects may be designed for public calls, and may be used to allow customers to customize their specific software install. The public objects may be configured to accept outside calls without generating side-effects, but also may be limited in functional scope. The core software suite may not easily be extended with access to just the public objects. To build whole applications on top of a released version the public objects and associated interfaces are often not complete enough from a functional point of view. To add a highly integrated AddOn application, e.g., an MBA, may require access to both public and private functions, e.g., internal functions.
Further still, modifications to the core objects may need to be done to enable an MBA. Modifications are changes to objects which belong to the underlying application and which are not part of the MBA delivery. Allowing the MBA to change any development object affords great flexibility, but may also create risk of side effects and conflicts when the underlying application delivers a new version of modified objects (e.g. via service packs, enhancement packs, and new releases). Product ERP (“Enterprise Resource Planning”) by SAP AG may be used herein as an example of an underlying software suite and core functionality, but other examples from the same or other developers may also implement the example systems and methods described herein.
An example of the overwritten object problem may be illustrated with reference to a released version of the ERP (e.g., ERP 6.0), which is already released and used by many customers. ERP 6.0 includes an extremely large number of development objects, one example may be a class with the name CL_CALCULATE_EXAMPLE. A MBA which is an AddOn based on ERP 6.0 may also be using class CL_CALCULATE_EXAMPLE. This is possible since the class belongs to the underlying product. However, the MBA may need the functionality of the class to be a bit different. For example, it may need CL_CALCULATE_EXAMPLE to return additional values. The MBA may therefore change this class and deliver the adapted (i.e. modified) version of the class to customers with the MBA delivery. In customer systems the existing version of the development object (e.g., the version delivered with the ERP 6.0 shipment) will be overwritten and the extended version may then be available.
At this point, assuming the extension to the class was properly coded (e.g., has no unintended side-effects to the ERP), there should not be any conflicts. However, ERP 6.0 is delivering Support Packages (“SP”) and Enhancement Packages (“EHP”) to customers. These deliveries could also contain the class CL_CALCULATE_EXAMPLE, as this class belongs to the core ERP, and it might be corrected or enhanced by the core ERP development teams. Customers who install these ERP SPs and ERP EHPs to their systems may then get class CL_CALCULATE_EXAMPLE again. This may overwrite the version delivered with the MBA, the one containing the modification. Since the modification is no longer in the customer's systems, the MBA may have serious problems when calling the overwritten version.
The above illustrated problem with modifications is generally known, and may be solved with so called conflict resolution transports (CRTs). Customers may no longer be allowed to install the core SP to their system directly, but only in combination with a conflict resolution transport. This CRT may contain a resolution of any conflicts. In the simplest case it may just contain the modification again (e.g., modifying the new version similarly to how the MBA modified the older version). In more complicated cases it might also contain additional adaptations that may be needed to work with the new core SP/EHP. This could mean that it contains even more modifications or a changed/adapted version of the previous modification. Installed together with the ERP SP/EHP the CRT may ensure that the right version of the modified object is available in the customer system. However, building CRTs requires substantial effort and the CRTs have to be built as long as there are new SPs/EHPs (e.g., indefinitely). Further, the complexity increases as each new EHP may have its own maintenance line which means its own SPs for which CRTs also have to be offered.
Example embodiments of the present invention minimize the maintenance burden of CRTs in the context of MBAs and enhancement packages described above.